As the demand increases for varying types of applications within mobile telecommunications networks, service providers must constantly upgrade their systems in order to reliably provide this expanded functionality. What was once a system designed simply for voice communication has grown into an all-purpose network access point, providing access to a myriad of applications including text messaging, multimedia streaming, and general Internet access. As seen in second and third generation networks, voice services must be carried over dedicated voice channels and directed toward a circuit-switched core, while other services are transmitted via the Internet Protocol (IP) and directed to a different, packet-switched core. This led to unique problems regarding application provision, metering and charging, and quality of experience (QoE) assurance.
In an effort to simplify the dual core approach of the second and third generations, the 3rd Generation Partnership Project (3GPP) has recommended a new network scheme it calls Long Term Evolution (LTE). In an LTE network, all communications are carried over an IP channel from user equipment (UE) to an all-IP core called the Evolved Packet Core (EPC). The EPC then provides gateway access to other networks while ensuring an acceptable QoE and charging a subscriber for their particular network activity.
The 3GPP generally describes the components of the EPC and their interactions with each other in a number of technical specifications. Specifically, 3GPP TS 29.212, 3GPP TS 29.213, and 3GPP TS 29.214 describe the Policy and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF), and Bearer Binding and Event Reporting Function (BBERF) of the EPC. These specifications further provide some guidance as to how these elements interact in order to provide reliable data services and charge subscribers for use thereof.
For example, 3GPP TS 29.212 provides guidance on the format of messages passed between the various components. 3GPP TS 29.212 specifies that the EPC components will communicate using the Diameter Protocol and Attribute Value Pairs (AVPs). The specifications further provide more specific definitions of protocols and messages over several interfaces within the EPC and definitions of individual AVPs.
The specifications allow a great deal of flexibility in constructing messages. For example, most message definitions in 3GPP TS 29.212 allow for the addition of extra undefined AVPs. Additionally, the Diameter Protocol allows messages to contain multiple AVPs without a specific order. Messages of different types may use the same AVP in different situations with different meanings. This degree of flexibility however creates problems of interoperability as component manufacturers implement the specification differently. Because of the flexibility, there is no overall valid message format that can be used to validate every message. Moreover, implementations have changed over time and legacy systems may use different message formats. This has resulted in generally weak validation to accommodate the degree of flexibility in message format.
In view of the foregoing, it would be desirable to provide a method to ensure interoperability between messages received at a network component. In particular, it would be desirable to provide message interoperability which maintains the flexibility of the specifications and allows for specific variations and modifications.